Take a parser SyntaxError's sourceURL from the same source-mapped frame as its line - #47698

Repro

// first.ts
export const first = 1;
// second.ts
export const a = 1;
export const b = 2;
export const re = /(/;
// entry.ts
import { first } from "./first.ts";
import { re } from "./second.ts";
console.log(first, re);

bun build --target=bun --sourcemap=linked --outdir=out entry.ts
bun -e 'try { require("./out/entry.js") } catch (e) { console.log(e.line, e.sourceURL, e.stack.split("\n")[1]) }'
# 1.4.3: 3 <dir>/out/entry.js     at <parse> (<dir>/second.ts:3)
# now:   3 <dir>/second.ts        at <parse> (<dir>/second.ts:3)

The bundler does not check a regular expression literal, so the error comes from JavaScriptCore. No issue reports the mixed pair. It was found by reading the block. It dates from #10998, which let the source map of a bundle rename the file.

Why both values name the file of the mapped line

• formatStackTrace writes line, column and sourceURL of an error with frames from one remapped frame (the if (!hasSet) arm, Fix various bugs with function names and source mappings involving eval and node:vm #16212). The <parse> block sets hasSet, so that arm does not run for a parser error.
• test/aot/stack-frame-paths.test.ts:1-3 states the rule: "Whatever reads a frame's file gets that text: Error.stack, call sites, error.sourceURL, console.trace and the uncaught-exception printer."
• sourceURL is now the file that the at <parse> line of .stack names. Both come from one lookup at column 0 of the generated line: a source file where the lookup finds a mapping, the loaded file where it does not.
• A file that Bun transpiles at run time has one URL before and after the map. With both values in the loaded file, its line would be a line of the transpiled text.

error.sourceURL by shape (line and .stack are the same on 1.4.3 and on this branch)

• --minify: the lookup at column 0 finds the first mapping of the generated line. The parser knows the column of the error and JavaScriptCore does not pass it on (Incorrect line and column numbers when SyntaxError happens #5192). A failing test records this case.
• Below the outdir root: the bundler writes sources relative to the outdir root and the runtime joins them to the folder of the bundle (Sourcemap source root not clear #3332, bundler: write source map sources relative to the file that carries the map #47548).
• node:vm and module._compile: the source map table is keyed by path, so text that runs under the name of a loaded bundle is mapped through the map of that bundle. line was already mapped on 1.4.3 and sourceURL was the filename. node:vm: keep a vm SyntaxError's parse location out of the source map of the file its filename names #38362 proposes to keep such text out of the map for node:vm. It has had no update since 2026-08-14.

A structured clone

structuredClone(e) copies line and sourceURL. If the copy gets frames later (Error.captureStackTrace), the block runs again with those values. 1.4.3 maps the mapped line a second time through the map of the bundle: { line: 1, sourceURL: "out/entry.js" } and at <parse> (first.ts:1). Now the copy starts from second.ts, which has no map: { line: 3, sourceURL: "second.ts" }.

The printer

The error printer falls back to sourceURL and line when the stack has no frame that it can parse. With the mixed pair it printed lines of the bundle under the line number of the original:

1 | // @bun
2 | // first.ts
3 | var first = 1;
    ^
SyntaxError: Invalid regular expression: missing )
      at out/entry.js:3:1

It now prints lines 1 to 3 of second.ts and at second.ts:3:1. In a --compile --sourcemap executable sourceURL is the bare name second.ts, so this fallback opens that name in the current directory. 1.4.3 printed the first lines of the embedded bundle there.

exceptionFromString prints a thrown object that is not an Error. It printed sourceURL:originalLine (#3441, with TODO: don't sourcemap it twice). At that time the printer mapped the position again at column 0, so it needed the line before the map. Since #22739 the printer passes the missing column as it is, and a source map that is already parsed then has no mapping for the frame. sourceURL is the file after the map since #16212. So the pair was a file after the map with a line before it:

• The handlebars object has its own originalLine (the place of the capture, before the map) and inherits line and sourceURL from its prototype. Neither build prints the place of the throw.
• A DOMException has the line and sourceURL that JavaScriptCore gave it when it was made, before the source map (line 6 above is line 8 without the two comment lines over it). Error.captureStackTrace then gives it an originalLine, the line of the capture. pg, pg-pool and undici call it on what rejected. 1.4.3 printed the file of the one with the line of the other. The printer now shows the DOMException's own position.
• So the frame is not marked as remapped, which fromErrorInstance does for an Error with originalLine: on another object originalLine does not show that line and sourceURL are mapped. Measured with the mark: a bundle that aborts on src/app.ts:9, with a dependency outside the bundle that calls Error.captureStackTrace on the rejection, prints at out/app.js:6:1. Without the mark it prints at src/app.ts:9:1 (1.4.3: at src/app.ts:2:1).
• The printer also reads the file that a remapped frame names from the disk, and an object that is not an Error (parsed JSON that is thrown) can name any file. The test row object pins this: no source lines.
• Not marked, the frame can be mapped again in one case: its sourceURL is a module that this thread loaded and whose source map nothing has parsed yet. Then the first parse looks the frame up at column 0 (src/jsc/SavedSourceMap.rs:369). Measured with a bundle written over its own source (--outdir=.) and an object posted from a worker: 1.4.3 prints index.js:3, this branch index.js:1. Once the map is parsed, 1.4.3 prints index.js:6 and this branch index.js:3.
• DOMException: record source-mapped positions and a Bun-format stack on internally created exceptions #39320 edits the same lines and sets remapped when the object has originalLine. It also gives a DOMException a mapped position, which that rule needs. error: do not read a frame's source URL from disk unless the loader loaded it #41477 limits which files the printer reads.

Not changed here

• The <parse> block looks up column 0 of the generated line. On an indented line Bun's printer puts a mapping there that repeats the previous position, so line can be the line of the previous statement (Incorrect line and column numbers when SyntaxError happens #5192). The tests use statements that are not indented.
• A module that fails to parse with no JS frame on the stack (import(), a static import, the entry point) never reaches the block. It keeps the parser's line and the loaded file, and it has no stack.
• Under a callable Error.prepareStackTrace the formatter writes none of the three properties.
• Error.captureStackTrace on a module parse error gives it frames. A read of line, sourceURL or stack while those frames are alive goes through the block and now stores both values. If a collection finds a captured frame dead first, it formats the stack with no error and the block does not run: the location is the place of the capture, as on 1.4.3.
• bun test --reporter=junit on a test file that is a bundle writes file="dist/thing.test.js" line="14" for a file of 10 lines. bun test --coverage lists dist/lib.js with uncovered lines 13-15, which are lines of src/lib.ts. Both pair a mapped line with the loaded file and are the same on both builds.

Measurements (release builds of main 3f3a9ff and of this branch, bun run build:release, x64 Linux)

The disassembly of formatStackTrace has 1813 and 1831 instructions. Outside the <parse> block two instructions differ (the register that holds a zero). No export, host function or property name is added.

Probed cases: require and its aliases (module.require, createRequire, Module._extensions, ...), import(), Error.captureStackTrace, structuredClone, node:vm and module._compile, for a sidecar map, an inline map, a CommonJS bundle, a file with no map and a file that Bun transpiles. 31 of 53 change on the first read, all in sourceURL. 6 of the 31 are the node:vm and module._compile cases. No case of a file with no map, of a transpiled file, of Error.prepareStackTrace or of a frameless import() changes.

Self-review: what was not done

• Six concerns ask to make the lookup exact before this store lands, or to guard it: with the parser's column from JavaScriptCore, or by not mapping a generated line that has mappings of several sources. Not done here. The store is the same statement in that end state, the lookup has its own issue (Incorrect line and column numbers when SyntaxError happens #5192), and a guard changes the at <parse> line and the uncaught output of minified bundles. The minified case is a test.failing with the value it must have.
• Failing tests for the node:vm and module._compile rows are not added. node:vm: keep a vm SyntaxError's parse location out of the source map of the file its filename names #38362 has tests for the node:vm rows.
• A review comment on this PR asked to mark an object with originalLine as already mapped. Not done, for the DOMException case above.
• Two cases above have no tracker: the first parse of a source map looks a frame with no column up at column 0, and a compiled executable reads <cwd>/<name> for the source lines of a frame that is already mapped. No issue is filed with this PR.

Other open PRs on these lines: #45667, #37386, #37432 and #38362 edit the <parse> block and do not write sourceURL. #46554 moves the block into syntaxErrorParseFrame(..., OrdinalNumber& line, bool& hasSetLine), which would need to pass the URL too. #39320 and #32898 edit exceptionFromString.